Deployment of maintenance packages to computing platforms often requires downtime of such platforms. At the beginning of downtime, a backup is created and this backup serves as a fallback option, in case the upgrade fails. Advancements in technology have enabled for reduced, and in some cases, zero downtime upgrades. With such arrangements, upgrade procedures run in parallel to a production system within the same database for the complete duration of the upgrade. The procedure creates clones of the tables, which are changed by the upgrade and runs database triggers to replicate data from production to the upgrade copy of the tables.
With a zero downtime upgrade, the upgrade procedure and the production operate against the database at the same time. The upgrade tool potentially reads data from the database, and derives actions out of the data read. If the data is later changed by an application forming part of the production system, the results of the upgrade are invalidated. The entries read by the upgrade must therefore be locked against writing in the production system.